Store state when sending commitment_signed
#13
Conversation
|
@niftynei @dunxen @morehouse this commit adds the requirements addressing in this comment. Let me know if that's clear enough, and any feedback you have from implementing it or going through the message flow scenarios described in my comment or in https://gist.github.com/t-bast/1ac31f4e27734a10c5b9847d06db8d86 |
|
Thanks for this and for enumerating the disconnection scenarios in the gist! It seems clear IMO, but I will bring it up in LDK's project sync this week and see if there's anything glaringly tricky here. :) |
t-bast
force-pushed
the
dual-fund-reestablish
branch
from
eccee2d to
cc1b3d8
Compare
|
I slightly updated the requirements: the receiver of |
|
Thanks, LGTM! |
If we only store state when sending `tx_signatures`, there are cases where we cannot reconcile states if a disconnection occurs during the signing steps: one side will have sent `tx_signatures` and thus must wait for the transaction to be spent or double-spent, while the other side has already forgotten that channel because they haven't sent `tx_signatures`. This is fixed by storing state when sending `commitment_signed`, and adding a `next_funding_txid` field to `channel_reestablish` to ask our peer to retransmit signatures that we haven't received.
t-bast
force-pushed
the
dual-fund-reestablish
branch
from
b6c4c7c to
248caeb
Compare
|
Squashed the fixup commit in 248caeb |
If we only store state when sending
tx_signatures, there are cases where we cannot reconcile states if a disconnection occurs during the signing steps: one side will have senttx_signaturesand thus must wait for the transaction to be spent or double-spent, while the other side has already forgotten that channel because they haven't senttx_signatures.This is fixed by storing state when sending
commitment_signed, and adding anext_funding_txidfield tochannel_reestablishto ask our peer to retransmit signatures that we haven't received.